SYSTEM AND METHOD FOR PRIVATE AND SECURE 
FINANCIAL TRANSACTIONS 

Inventors: Len 3L Mizrah 

BACKGROUND OF THE INVENTION 
Field of the Invention 

The present invention relates to a system and method for providing a p rivate and 
secure transactions transaction environment . 

Description of the Related Art 

Basic financial transactions including buy and mor e particularly to a system sell 
transactions and method for providing private withdraw and s e cure buy/seller 
withdraw /deposit transaction environment within financial institutions and at m e rchants / 
sellers / vendors transaction-processing systems. 

D e scription of the Relat e d Art 

Basic financial transactions including buy/sell and withdraw/deposit , have always 

required security to protect the financial account holder, the financial institution where 
the account resides, and a merchant/seller/vendor - or other party at the point of sale from 
identity theft and fraudulent transactions. Due to wide spread use of computer networks 
and electronic commerce as a new medium to perform transactions, new requirements to 
maintain validity and integrity of financial transactions are arising. There are companies 
violating consumer privacy by gathering, sorting, researching and selling for profit 
consumers'- private personal information about consumers acquired during financial 
transactions. It would be advantageous to provide an efficient system and method to 
protect customers' privacy during financial transactions. Another new requirement is 
associated with the fact that hackers and intruders getting an may get illegal access to the 
computer network ea^ -and compromise financial transactions. This aspect of 
transactions 1 security is addressed in U.S. Pat. No. 6,092,202 to Veil et al. 

Throughout the entire-history of financial transactions, privacy and security were 
have been addressed by- using the best contemporary technologies. Since the onset of the 
computer network era, computer power, relational databases, software environments and 
communication lines have been used by financial institutions for security and privacy 
functions. Banks, then credit card companies and eventually brokerage companies and 
other financial institutions have used them computer systems to perform authentication, 
authorization and accounting, referred to as AAA, at their back offices during financial 
transactions. 

Financial transactions with credit cards suff e r significant loss e s due Due to 
weaknesses in implementing -the authentication stage efin financial transaction^ ^ with 
credit cards, consumers have suffered significant losses. The authentication stage is based 
on a p arty at the point of sale who compares human signatures visually on a card (if there 
is any) and on a selling slip. This operation is error prone when identifying faked 
signatures in a cas e of fraudulent actions. If a financial Also, if an account holder loses an 
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unsigned credit card a it is easy to fake signatures as one can place any signature on a card 
before requesting a financial transaction. Another typical malfunction at the 
authentication stage nf finnncml transaction credit card transactions occurs when 
someone gets a credit card account number and a copy of the card owner's signature. 
This enables fraud even with non-stolen credit cards. Another example where-in which 
financial institutions incur losses is earn e d by financial arises when account holders T 
when they change their minds after concluding a financial transaction. A financial An 
account holder can repudiate the financial transaction by claiming that somebody 
transacted in his or he r their place. 

These examples show that there is a real and substantial need for as 
improv e d improvements in financial transaction arcliitccture architectures at the 
authentication stag^ nf finnncinl tmnnnntinn. The fact that mistak es . Mistakes in 
authenticating "™ mnl rr*<Ht r.nrH nvvnern fraudulent actors are often followed by 
successful authorization and accounting sessions at financial institution back offices 
iltostrate . illustrating another weakness of the prior art financial transaction architecture. 
Authorization This occurs because the authorization and accounting stages are de- 
coupled from the actual financial-account holder, while the authentication stages are de- 
coupled from financial institution back office computers. 

Though credit cards have been used as a financial transaction instruments since 
the beginning of electronic commerce, there is anumber of issues in the electronic 
commerce architecture that have become apparent. For instance, credit card data, a social 
security number, a card holder name, a phone^ number, an address etc., while transferred 
through the Internet, are not absolutely secure and can fall into "wrong hands" due to 
communication channel leaks. It is obvious that while the high speed data flow through 
the Internet or other communication channels is a big advantage for financial 
transactions, insufficient data security makes it highly desirable to alter the financial 
transaction architecture to avoid potential dat a leaks on communication linca (Internet 
and non Internet an well). 

Another issue jeopardizing financial transactions in electronic commerce is 
weakness of the authorization stage of financial in credit card transactions with credit 
eafds. Neither the authorization stage nor the accounting stage are actively controlled and 
timed by financial thg_account holders. Nnmharn of non request e d A number of 
fraudulent sell transactions may happen before a financial thg_account holder regains 
control on his/her accoun t after it has been breached . U.S. Pat. No. 5,485,510 to Colbert 
and U.S. Pat. No. 6,052,675 to Checchio disclosed disclose attempts to improve the 
authorization stage of financial transactions in order to enhance financial transaction 
security. The Colbert patent proposed to alter financial transactions by authorizing a 
financial an_account holder before he/she applies to a merchant (a vendor). Information 
supplied to financial institution back office includes a credit card account number, a 
secret PIN and merchant / financial tranaaction specific information (specific to the 
merchant and the financial transaction (including at least, amerchant ID number and 
financial a transaction -amount). Then the merchant is given only the authorization code, 
while the card number and the PIN remain unknown to the merchant- or anybody, if the 
r„nrd in lont nr ntolon. Simila r . A similar architecture is offered in the Checchio patent, 
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except a merchant does not get any authorization code, but rather a credit card account 
number. Since the financial transaction -is pre-authorized in this case, a merchant sends 
into the financial institution back office a credit card account number and merchant /and 
financial transaction -specific information, which is compared with data given by the 
feaneial-account holder during the pre-authorization stage. Neither a merchant nor 
anybody can use the card without knowing a secret PIN, if it is lost or stolen. Useofa 
lost or stolen card is prevented in the Checchio sv stem using secret PIN. 

Though both pntnntr, nllow Colbert and Checchio improve security against 
fraudulent usage of credit cards for certain types of transactions, there are limitations to 
be addressed. Both patents are centered on phone lines, when communicating to financial 
institution back offices. Frequent usage of a pair of static numbers (account numbers and 
PINs) over phone lines is insecure due to leaks at the line entries and on the lines 
themselves. This insecure communication line issue gets aggravated, if one would like to 
replace phone lines by wireless or the Internet communication lines. Another weakness 
common to both patents is lack of a system and / or method as to how tho financial 
institution technolo gy enabling the back office is suppos e d to handle theproposed 
architectural changes for mass large numbers of financial transactions. Financial 
transaction architectures ought to cover SnaneiaJ-account holders, financial institutions 
and a party at the point of sale in a mutually dependent way. A nec e ssity to havo prior to 
rtm mithnriTitinn ^tifP Both prior art approaches require k nowledge of a party at the 
point of sale and other financial transaction -specifics prior to the authorization stage. 
This requirement for authorization is an additional limitation in both proposed 
i ^nnvnfinnn Thnt nnrrows Colbert and Checchio. narrowing down thetypes of possible 
financial transactions and fhejocationsrffijrom which they can be performed from.. 

There is a public concern that financial transactions with credit cards cither m 
electronic commerce channels er and in other traditional channels could lead to private 
personal consumers' information about the consumer b eing accessed, monitored, tracked, 
stolen and fraudulently used or sold for profit eftea-without the consumers' approval. _ 
Privacy related problems are exacerbated with the advanced Internet related technologies 
due to the ease with which information can be collected, processed and combined with 
other information. 

It is not only financial transactions with credit cards wtt^thatraise numerous 
privacy issues. Eves -For example, an account holder would not alw ays like a bank teller 
during standard withdraw/ and deposit financial t ransactions- at a bank , a financial 
account holder would not always like a bank teller to have access to his/her private 
personal information file. It would be beneficial if a financial anaccount holder could 
decide whether this privilege should be given to the bank teller. More often than not, 
withdraw/ and deposit ikreaeial-transactions- at a bank require financial an account holder 
to reveal identification documents to bo revealed, which can bo viewed as a certain This 
requirement to reveal personal identification documents is a p rivacy related 
inconvenience justified by the current state of the authentication architecture 
durmg process for such financial transaction. 

FIG. 1 A illustrates a block diagram of a conventional system for performing 
withdraw /and deposit transactions. In order to perform financial transactions, a legal 
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adult 101 (or a legal business) in nupponcd to have sets up an account with a financial 
institution. It is standard to di o clos e T ypjgall^ a privaterpersonal information profile 102 
is disclosed to the financial institution -during the account application processJ03. At 
step 104, the financial institution, which permitted an account opening, creates a personal 
log file in the financial institution back office, establishes a withdraw Aanddeposit 
mechanism, and issues personal checks and cards. Then fea«eial-the_account holder^ 
wheth e r it is a legal person 101 or a l e gal busin e ss, can perform deposit 105 or withdraw 
106 transactions. Typical deposit transactions to a bank or a brokerage house 107 are 
made teeugh-either a direct / mailed deposit with a personalized deposit slip 109 or by 
submitting a a personal check- on one's name and ^disclosing ene^sa name and account 
number. Another way of obtaining deposits is-used by insurance 1 17 and credit card 
companies 115, wfeeh-is to receive pawl- payments for account statements 119 from 
fkiafteial-an account holder. Checks 1 10, debit cards 1 12 or Graphical User Interfaces 
(GUI) over the Internet 1 13 are used by foaeeial-account holders for withdraw 
transactions with a bank or a brokerage house 108. The credit card 1 16 is a typical 
withdraw mechanism for withdraw transactions with credit card companies (wh e ther they 
are including banks like Visa and Master Card other types of financial institutions, 
like American Express). Another withdraw mechanism is used by feaneial-account 
holders when dealing with insurance companies 118. A request for payment 120 is to be 
made in accordance with the insurance policy. 

There are deficiencies in the deposit Aand withdraw transaction system described 
above related to privacy and security of the financial-account holder and ^financial 
institutio n performing tran s actions^ including the following: 

1) Direct and urgent deposit transactions can be hindered, if the fieaneiai-account 
holder is located far away from the bank and its branches where the account resides. It 
should be possible to deposit to one's account via other financial institutions, without 
disclosing private-personal information o f financial account holders at ether financial 
institution s-intermediate service levels? 

in other financial institutions. 

2) During depositing, bank tellers get access to the private-personal information 
0 f the fiftafteiakiccount holder. There are two issues here. Firstly, a teller can make 
mistakes altering personal and account balance information without any immediate 
financial institution back office CWcomputer and dB- database control. In other words, 
each deposit transaction has a probability of mistakes, hurting the bank and the financial 
account holder. Secondly, the financial-account holder may not like a bank teller to have 
access to his / her pjivate-personal information file during a direct d o positing. deposit^ 
transaction. At this stage it would be beneficial, if fiaaeeial-account holder could decide 
him- / her-self whether this privilege should be given to the bank teller. 

3) Insufficient theft and fraud protection during wMrawwithdrawal transactions 
with checks, credit, charge and debit cards or during electronic commerce financial 
transactions. 
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4) Private pcr s onal Personal information is not protected and often intentionally 
or unintentionally misused by a party at the point of sale or bank tellers during 
withdraw w ithdrawal transactions. 

FIG. IB illustrates a block diagram of a conventional system for performing buy / 
and sell transactions. Once financial account holder 121, has made a buying decision 122 
and applied to a party at the point of sale, the actual selling transaction is enabled through 
cash 124, credit cards 116, debit cards 112, checks 1 10 or electronic commerce 125. 
Though cash is handy for low value financial transactions, it is usually impractical for the 
bulk of mass financial transactions due to low cash amount on hand. All other financial 
transaction -instruments except cash, such as credit cards 116, debit cards 1 12, electronic 
commerce 125 and checks 1 10 lead to either complete or partial disclosure of private 
personal information 127, and are therefore prone to private personal information misuse 
and fraudulent actions 128. 

FIG. 2 illustrates a block diagram of a conventional system and method for 
performing authentication, authorization and accounting sessions during buy / sell 
transactions with a credit card, a charge card or a debit card. As illustrated in FIG. IB and 
FIG. 2, once a financial an account holder 121 has made a buying decision 122 and 
applied to a party at the point of sale, a point-of-sale (POS) device scans static 
information on a credit card and sends an authorization request to the_financial institution 
back office, specifying apri ce (money transaction amount), to perform a withdraw 
transaction 205. The financial institution back office €i4J computer checks whether there 
is enough money in the database under this account and if yes, and if the card is not 
marked in the database as lost, stolen or fraudulently used, authorizes the withdraw 
transaction 206-(i^seftds i sending an authorization code to the point of sale POS device). 
Steps 205 and 206 constitute the authorization stage 201 of the financial transaction. It is 
worthwhile to note that in the conventional financial transaction -system with credit / 
debit cards, the authorization stage is performed prior to the_authentication and the 
accounting stages of the financial transaction. 

Once the transaction authorization is sent to a party at the point of sale 206, the 
first accounting step 202 is performed. The account unde ^involved in the transaction is 
left with a locked sum of money to assure a payment to a party at the point of sale 207. 
The payment is made after deduction of the transaction fee to the card issuing bank and 
the discount rate fee to the acquiring bank or an independent sales organization, which 
provided fte-merchant status to a party at the point of sale. Once step 207 is completed, 
the financial institution back office is ready for another transaction of the same financial 
account holder, provided the requested spending limit is not exceeded. 

Then if the credit card is signed, the signatures on the selling draft and on the card 
are visually compared at-bva party at the point of sale for offline financial transactions 
208. If the card is not signed, identification documents are requested from financial 
account holder 209. Steps 208 and 209 are components of the authentication stage of 
financial transaction -203 for the conventional offline financial transaction -system. It 
can be noted here that the signature comparison step 208 is skipped by the conventional 
electronic commerce on line financial transaction -system based on credit / debit card 
usage dripn nt n p ?.Q8. nnri inntoad cnforceo Such electronic comme rce systems enforce step 
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209, requiring €jwite-wider disclosure, than in a case of offline financial transaction, of 
financial account holder private p ersonal information about the account holder. Then the 
final step of ^accounting stage 204 is performed. Step 210 includes the following: a 
party at the point of sale sends the selling draft inside the selling batch after trade hours to 
the acquiring bank (or an independent sales organization). The acquiring bank re-routes 
the respeetiwrelevant part of the batch to the card issuing bank4e-rak>6 k 1 which unlocks 
the payment and fransfe ftransfers it to a merchant account after deductions, specified in 
the merchant's agreement. Then in few days, t he money is placed into a merchant 

accoun t in few days. 

The conventional financial transaction -architecture based on credit Aordebit 
cards and shown in FIG. 2 has thn following a number of w eaknesses, which the present 
invention addresses^ 

, including the following: , . 

1) AntWiontio nThe authentication stage is de-coupled from financial institution 
back office CPU and dB, making it subjective, embarrassing, error and fraud prone. 

2) Antlinri/ntio ftThe authorization stage is de-coupled from ffflaaeial-account 
holder for both on and offline financial transactions, making it especially dangerous for 
on line financial transactions ffor example, due to on line financial transaction -latency, a 
number of unauthorized financial transactions may happen before feiafteiaJ-account 
holder regains control on the account). 

3) Private pcrsonal Personal information leaks are possible on the Internet 
communication lines during electronic commerce sessions (browsing technology, TCP/IP 
protocols, PKI, SSL and other Internet technologies do not guarantee sufficient financial 
transaction security). 

4) ArnnnntirifT The accounting stage is de-coupled from Snaneiakiccount holder, 
Vnnping nun nt potentially causing inconvenience during a series of buy Aand sell 

financial transactions. 

5) A party at the point of sale may collect and analyze feaneiMpersonal 
information about the account holder p r ivate personal inform a tion , and market and sell 
tithe information for profit. This leaves the public at large unaware of the privacy and 
confidentiality status of the data. 

Present on line and off line financial transaction -architectures have substantial 
security and privacy deficiencies at the authentication, authorization and accounting 
stages. It would be highly desirable to provide an improved system and method wherein 
consumers can perform financial transactions with financial institutions without privacy 
and security concerns. The present invention addresses these problems. 

SUMMARY OF THE INVENTION 

It is therefore an object of the present invention to cut off access by merchants^ 
sellers /-and vendors from consumers' privat e topersonal information about consumers 
during financial transactions. 

A further object of the present invention is to allow a - financial an_account holder 
to cut off access bv bank tellers from their to private personal files of account holders 
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during withdraw / and deposit transactions. 



A further object of the present invention is to provide a method, which couples 
together a financial anaccount holder and a financial institution b ack office during the 
authentication stage of financial transaction to insur e highly o lovatod and e nhanced 
enhance security of financial transactions. 

A further object of the present invention is to create tfeean authentication stage 
architecture ef-for financial transactions, which makes the authentication stage of a 
financial transactions a transaction-specific-ene; e.g. it can be used j«st-for_only fe^one 
particular financial transaction. 

A further object of the present invention is to include the beginning of the 
accounting session of a financial transaction -krtein the authentication stage architecture 
of financial transaction-^ to enhance ^.transaction specific authentication architecture. 

A further object of the present invention is to architect a financial transaction 
authentication session in a way that makes a a time specific, p ositive authentication 
ou tcome a time specific or t e -for a particular financial transaction-. 

A further object of the present invention is to design a system and to provide a 
method for financial transactions that enables merchants^ sellers-/-, and vendors to 
request authorization and accounting from a financial institution -back offices te 
authoriz e and to account financial tranaaction just for one particular financial transaction 
requested by fi nancial account holder. 

A further object of the present invention is to include the end of the accounting 
session mte-inthe authorization stage architecture of financial transaction. 

A further object of the present invention is to create afmancial transaction 
architecture that provid e a p rovides a high security level even in an environment with 
possible leaks on communication line s, such as mav occur due to incomplete security efin 
such Internet technologies as SSL (Secure Socket Layer), TCP/IP protocol, WEB 
browsers etc. 

A further object of the present invention is to provide "clocked" AAA for 
financial institution back offices that allows implementation of financial transaction 
specific AAA architectures. 

The present invention is a system and method for providing private and secure 
financial transactions. The system and method comprise a "clocked" AAA method 
embedded into financial in s titution back office privacy layer architectures. The 
architecture comprises "back office connection devices" for use by financial account 
holders to connect to financial institution back offices. Such devices include for example 
regular phones, and personal computers with a specific Graphical User Interface (GUI) 
invoked through a Universal Resource Locator (URL) address. Alternatives include 
network computers or wireless personal organizers, interactive TV set sessions or smart 
cards with customized read / write devices to interact with financial institution back 
offices. The architecture comprises also a financial inotitution back office central 
processing unit ("the CPU"), which could include a farm (or cluster) of compute and file 
servers operated under eifee rfor example UNIX Sun/Solaris or Windows NT operating 
systems; a number of software programs (software modules) designed to implement 
various functions of the_"clocked" AAA; and a relational database (dB) inside financial 
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institution back offices, where the actual account information is stored and accessed. The 
financial institution back office includes a dB -connected to the CPU where information 
is processed using the "clocked" AAA program environment. 

The present invention allows consumers having membership with any financial 
institution -to perform financial transactions in a highly secure and private manner. 
Financial accountAcjgount holder pfwatenpersonal information need not be disclosed to a 
party at the point of sale aer- or to a bank teller. Finally, the system and method are well 
adapted to the current and upcoming software, hardware and electronic commerce 
technologies and can be easily implemented given an acceptable business trade off. 

A method for managing financial transactions according to the present invention 
includes performing an authentication process, an authorization process and an 
accounting process. The authentication process is executed for a predicted transaction by 
a particular account holder. The predicted transaction has a predicted transaction amount 
and a predicted transaction time. The authentication process produces a transaction 
signature for presentation upon execution of the predicted transaction. The authorization 
process for a particular transaction has an actual transaction amount and an actual 
transaction time which are determined upon presentation of the transaction signature. 
The authorization process includes verifying that the presented transaction signature 
matches the transaction signature for the predicted transaction, that the actual transaction 
amount matches the predicted transaction amount, and that the actual transaction time 
matches the predicted transaction time. The accounting process for the particular 
transaction is performed as a result of a successful authorization process. The accounting 
process includes reconciling the predicted transaction amount and actual transaction 
amount for the particular account holder. 

According to one embodiment of the invention, the predicted transaction amount 
and the transaction signature for a predicted transaction are stored in an authentication 
record in a database at the financial institution back office. Likewise, an authorization 
record is created during the authorization process. The authorization record and the 
authentication record are compared to complete the authorization process for the 
transaction. Thus, the authentication record includes the predicted transaction amount 
and the transaction signature. Also, a predicted transaction time is stored in the database 
which holds the authentication record, as for example, a time out interval length used in 
combination with a time of creation of the authentication record, or for another example, 
as an absolute time value. 

One representative embodiment of the authentication process includes 
establishing a communication session between the particular account holder and the 
financial transaction server, accepting an account number as input, prompting the 
particular account holder to supply a static identification number at a first instance, and a 
dynamically identified combination of digits from personal identification code, where in 
the combination does not include all the personal identification code, at a second 
instance. Further, the predicted transaction amount is accepted as input. The transaction 
signature is produced and sent to the particular account holder. The information 
identifying the predicted transaction, and the time stamp are stored in an authentication 
record. 
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A representative embodiment of the authorization process includes establishing a 
communication session between a party to the particular transaction and a financial 
transaction server. At the server, a presented transaction signature is accepted and an 
actual transaction amount is received as inputs. The server compares the time of the 
particular transaction with the predicted time, and the presented transaction signature and 
the actual transaction amount with the predicted transaction amount and the transaction 
signature associated with the transaction. An authorization message is sent to the party to 
the transaction upon successful matching of the parameters. 

The process for managing financial transactions according to present invention 
works with or without identification of the taieiaJ-account holder during the 
authorization process. 

In various embodiments, the present invention comprises -a system which 
executes the authentication process, the authorization process, and the accounting process 
utilizing communication media interconnecting the financial institution back office with 
individual end stations, such as cell phones, point-of-sale devices, personal computers, 
handheld computers, and the like. In an alternative embodiment, the present invention 
comprises an article of manufacture storing computer programs used for executing the 
processes as outlined above. 

In yet other embodiment, the present invention provides a financial transaction 
server including communication resources, processing resources, and data storage 
resources utilized for managing the processes described above. 

The present invention also provides a method for automated authentication, 
authorization and accounting for financial transactions. The method comprises 
establishing an authentication record for a predicted transaction by a particular account 
holder. The authentication record includes information identifying a predicted 
transaction having a predicted transaction amount and a transaction time parameter. 
Also, an authenticated transaction signature for presentation upon execution of the 
predicted transaction is included in the authentication record. The method also comprises 
establishing authorization record for a particular transaction indicating an actual 
transaction amount, an actual transaction time and a presented transaction signature. The 
authorization record and the authentication record are matched to determine whether the 
presented transaction signature matches the authenticated transaction signature for the 
predicted transaction, whether the actual transaction amount matches the predicted 
transaction amount, and whether the actual transaction time matches the transaction time 
parameter. Finally, the predicted transaction amount and actual transaction amount are 
reconciled for the particular account holder. According to various embodiments, the 
method includes storing the authentication record in a database including a plurality of 
authentication records for predicted transactions. The process involves periodically 
attempting to match authentication records with authorization records being created with 
a timed algorithm, which automatically times out authentication records based on their 
time of creation and a parameter determining a length of time within which the predicted 
transaction must be completed. 

In sum, a secure and private financial transaction process is provided that can be 
deployed efficiently and which addresses many of the deficiencies of other existing 
systems. 
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Other aspects and advantages of the present invention can be seen on review of 
the drawings, the detailed description and the claims which follow, 
BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 A is a block diagram of a conventional system for performing 
withdraw/deposit transactions. 

FIG. 1 B is a block diagram of a conventional system for performing buy/sell 

transactions. 

FIG. 2 is a block diagram of a conventional system and method for performing 
authentication, authorization and accounting sessions during buy/sell transactions with a 
credit card or a debit card. 

FIG. 3 is a flow diagram of the embedded privacy and security layer EPSL 
architecture for either buy/sell or withdraw/deposit transactions. 

FIG. 4 is a flow diagram of the EPSL authentication session (while on financial 

account holder side). 

FIG. 5 is a flow diagram of the EPSL authentication session (while on financial 

institution b ack office CPU and dB side). 

FIG. 6 is an interface protocol of the EPSL architecture. 
FIG. 7 is a flow diagram of the EPSL authorization session. 
FIG. 8 is the EPSL transaction checklist. 

FIGS. 9A, 9B and 9C are a synthesis of a timing diagram, a flow chart and a 
functional diagram of the EPSL architecture based on the "clocked" AAA technology. 
DESCRIPTION OF PREFERRED EMBODIMENTS 

FIG. 3 shows a flow diagram of an embedded privacy and security layer EPSL 
architecture for buy / s ell and withdraw / dcposit fmancial transactions according to the 
present invention. Financial account A ccount holder 121 makes a transaction decision 122 
irrospoctive whether it is going to be on or off line financial tranaaction and independent 
of the location and manner in which it will be carried out , such as whether it will be an 
an on-line or off-line transaction and such as the location of a specific point of sale (or a 
bank telle r) locations . It is assumed at this stage that the financial account holder knows 
an approximate or exact amount of money, which will be required to perform the 
predicted financial transaction. Following the transaction decision (step 122), at step 301, 
the fiaafteial-account holder initiates an authentication session with a financial institution 
back office ryu ™A hp nrWn fimnr.inl nnmnnt hnlder server in whicht h e account 
holder's account resides. Betai teMore details of how the authentication session is 
performed at financial institution back office according to present invention is-are 
described later. However, several features of step 301 are disclosed here. 

The financial account holder has to go through three tiers of financial institution 
back office security protection, to initiate the authentication session. First two tiers are 
based-ea include disclosing a financial institution EPSL account number and then a 
transaction (deposit or withdraw) static PIN secret number, which are intended to be 
known only to fin ancial account holder and financial institution back office. Jn 
embodiments described herein, the account holder has a first stat ic PIN for a withdraw 
transaction, and a second static PIN for a deposit transaction. Since the financial 
institution back office may be accessed by a financial -an account holder through various 
dedicated communication lines, which do not have nee-guaranteed securit y protection , a 
third security protection tier of security protection is included. The third tier is based on 
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an interactive dialog between the fi nancial institution back office and the financial 
account holder. The back office prompts the account holder to enter a random subset of 
digits^ particular to the given communication session^ of an identity PIN secret number, 
which is known only to financial account holder and financial institution back office. The 
third security protection tier allows eliminating any of security protection eliminates 
potential information leaks at the entry devices and on the communication lines 
thcms Q lves. used for the transaction. Whoever intercepts the random digit combination, 
requested during the third tier processing from financial account holder, will not be able 
either reuse it or reengineer the entire identity PIN, 

Another- According to another feature of step 301 i s that A the financial institution back 
office prompts the financial account holder to enter the predicted transaction amount of 
money. Then, at the end of the authentication session 302, an alphanumeric transaction 
signature is generated at the financial institution back office 303 and transferred back to 
financial account holder. This signature is specific to a particular financial transaction 
amount requested by financial account holder, and has a limited life time, set by default 
to a reasonable time interval sufficient enough to perform the financial transaction. It 
should also be noted here that the alphanumeric signature can be used for only one 
financial transaction -and can not be reused. 

Once the financial account holder is authenticated for a particular financial 
transaction . there is . the account holder may still reom-ten chanae his/her mind and back 
off from the financial transaction. To execute the transaction, the financial account holder 
submits the alphanumeric transaction signature to a party at the point of sale (such as a 
merchant or a bank teller) along with a financial institution EPSL th^account number. 
Neither the alphanumeric transaction signature nor the financial institution EPSL 
account number contains any private-personal information, which could be associated 
with the financial account holder requesting by a party at the point o f sale to continu e a 
financial transaction . At step 305 a party at the point of sale initiates an authorization 
session with financial institution back office CPU and dB . server. In addition to the 
alphanumeric transaction signature and financial institution EPSL the_ac count number 
given by the fi nancial account holder, the party at the point of sale add^ provides a 
business ID and an actual transaction amount of money and then sends this time stamped 
information sequence along with a time stamp to the financial institution for authorization 
nt finnnrinl institution hack office. Th e detailed . More details about the system and 
method to perform an authorization session at financial institution back office will be 
discussed later. Information sent by the party at the point of sale (or by_a bank teller) for 
authorization is sufficient enough not only for forboth an authorization session decision 
making process 306, feutand for completion of the accounting session completion as well 
307. At this moment, the financial transaction -is completed in a highly secure manner 
without disclosing financial account holder private p ersonal information about the 
account holder to a party at the point of sale. 

The top l e v e l basic financial transaction -architecture disclosed above is applicable 
to on -line and off-line financial transactions, Though hardware and software 
environments at the point of sale locations (like POS devices, GUI, selection of 
communication lines etc.) may vary for each of those two cases, the fundamental 
architecture of private and secure financial transactions remains the same. The 
authentication stage, becomes the first performed step in the system and has paramount 
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priority and security enforcement. ftjfrtw rtThe authentication process does not involve a 
party at the point of sale any more , who authenticates the financial account holderr&rt. 
Rather, authentication is performed by the financial institution back office. it-This 
authentication process p revents fraud, embarrassment and pfivate- misuse of p ersonal 
information misus e b y a party at the point of sale (or by_a bank teller). The financial 
account holder can not repudiate the financial transaction, as nobody else could transact it 
in his or her place. The authorization and accounting stages of the financial transaction in 
the revealed system architecture can-not occur without a prior request by the financial 
account holder. Thus, authorization and accounting are coupled with the actual financial 
account holder, while authentication sessions feeeaffle-are_tightly coupled with the 
financial institution back office. 

FIG. 4 illustrates a flow diagram of the EPStauthentication session (from the 
financial account holder side). Basically, i tFIG. 4 is a more detailed flow diagram of 
steps 121 - 122 - 301 - 302 - 303 shown earlier in FIG.3, which all together constitute the 
authentication session for the financial aocount holder with tho financial institution back 
office. The financial account holder in exp e cted to with the financial ins t itution back 
office. The account holder may u se various devices and communication lines to be able 
te-reach financial institution back office. As illustrated in FIG. 4, example 
communication devices include point of sale POS devices 401, conventional phone lines 
and mobile phones 402, network computers 4 03 or wireless organizers 40 4 with URL / 
GUI capabilities 404_and desktop personal computers connected to the Internet (or 
specialized financial institution on-line services) 405. Once connection to the financial 
institution back office is established, the finanektl-account holder is first requested to 
enter a financial institution EPSL an account number 406 (the first security tier Kt for the 
ESPL account. Then the feianeial-account holder is requested to enter a transaction type 
specific, static PIN secret number 407 (the second security tier) and a requested random 
combination of digits from an identity PIN secret number 408 (the third security tier). 
Finally, the financial account holder enters an expected transaction amount of money 
409. A failure in making any of steps 406 - 407 - 408 - 409 leads to refusal by the 
financial institution back office to perform the authentication session. It is expected that 
the financial account holder at this point will try again to initiate an authentication 
session, or after a second rejection contact the financial institution -EPSL representative 
after the second rejection 308. Succonnful Upon successful completion of these steps-ends 
Hfi-wi A, the hack office server delivers an alphanumeric transaction specific signature 
generated at financial inst kutieajhe back office and transferred back to financial account 
holder 303. Step 409 is a last step in the authentication session, and it begins the 
accounting session at financial institution back office. In this step 409, the transaction 
predicted amount of money requested by financi a l -account holder is compared with an 
amount available in the account. The predicted a mount predict e d should not be less than 
the actual amount specified later by a party at the point of sale (or by_a bank telle r) during 
tho authorization session request. ^ It is important to note that step 303 will not be 
reached and the authentication stage at step 409 will be rejected, if tho cr e dit / debit 
financial institution EPSL card or account number associated with th e account is listed at 
financial institution back office as lost, stolen or fraudulently used. The authentication 
stage at step 409 will also be rejected, if the transaction amount of money requested by 
fkaneiaJ-account holder exceeds the available ene sfunds at financial institution EF SLfor 
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the account. 

FIG. 5 shows a flow diagram of the EPSL authentication session (from the 
financial institution b ack office CPU and dB server side ). Du e to a central position 
occupied hv an . where the server includes a CPU and a dB). The authentication session 
in the disclosed financial transaction -system architecture - is central to its operation. 
Thusit is necessary to show how financial institution back office system is adapted to 
handle the authentication session. A financialA n account holder initiates the 
authentication session with the financial institution back office 301 in the same way and 
through the same communication devices / channels as shown in FIG. 4. Although a 
detailed system and method of performing AAA at financial in s titution back office will 
be described later, certain features specific to the authentication session features are 
discussed here. 

The back office server in this embodiment includes a computer pr ogram including 
an ACCOUNT NUMBER SEARCH PROGRAM module 502. a TRANSACTION PIN 
VERIFICATION PROGRAM module 503. an IDENTITY PIN RANDOM SUBSET 
GENERATOR module 505. and an ACCOUNT CONSISTEN CY PROGRAM module 
507. 

At decision-making step 504, theACCOUNT NUMBER SEARCH PROGRAM 
module 502 is activated in the financial institution back office CPU / dB server , which 
transitions the authentication session to next decision-making step 506, provided 
financial institution EPSL account number verification is successful. At step 506 
TRANSACTION PIN VERIFICATION PROGRAM module 503 is activated and 
transitions the authentication session to decision-making step 508, provided transaction 
type PIN verification in the financial institution b ack office dB is successful. At step 508 
IDENTITY PIN RANDOM SUBSET GENERATOR module 505 is activated at financial 
institution back office CPU and transitions the authentication session to decision-making 
step 509, provided a random subset of digits is validated at the financial institution back 
office dB. At step 509 ACCOUNT CONSISTENCY PROGRAM module 507 is 
activated at the financial institution b ack office CPU and transitions the authentication 
session to decision-making step 511, provided the predicted t ransaction amount of 
money, specified by financial account holder during an authentication session does not 
exceed' available funds in the account. At step 51 1 the authentication session is completed 
at the financial institution b ack office and the accounting session is begun 510, unless the 
finnnmnl institution EPSL card account is flagged because for example the account 
number is in the list of lost, stolen or fraudulently use d accounts , which would lead to 
rejecting the entire authentication session. Otherwise, the authentication file will be 
generated, time stamped and put on hold at financial in s titution back office dB 
concurrently with the alphanumeric financial transaction -specific signature, which is 
generated and sent to the financial account holder. One may note that a number of 
program modules 502, 503, 507 and 510 are incorporated into financial institution b ack 
office software environment to perform an authentication session. This is just a part of 
the automated "clocked" AAA sessions, which constitute the system and method at 
financial institution - b ack office to enable financial institution EPSL technologyv 
for a financial institution- 
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FIG. 6 shows an interface protocol of the EPSL architecture. The columns 
correspond to processing nodes that process parameters - The rows 6 01-612 correspond 
to parameters involved in the procedures. A parameter name in a cell shows where the 
parameter is originated. If an arrow onset hoginn from th e occurs in a cell ? where a 
parameter is originated, an arrowhead shows where the parameter is delivered te-for 
further processing. If an arrow onset occurs in a cell location is-different than the cell 
location in the same row at which the parameter originates, this arrow shows a 
destination cell to which a parameter was moved for processing in an earlier exchange, 
and from which it is moved again as indicated by the arrow. 

Parameter ACC#JXYZ} 601 is the account number for the financial institution 
EPSL account-iiufflbef. "XYZ" should be broadly constructed to mean a certain number, 
which uniquely characterizes financial institution EPSL finoncial an account holder. 
Parameter W_PIN 602 is a withdraw transaction PIN secret number. Parameter D_PIN 
603 is a deposit transaction PIN secret number. Parameter W$ 604 is withdrawal 
transaction amount, specified by financial account holder during an authentication 
session. Parameter D$ 605 is a deposit transaction amount, specified by financial account 
holder during an authentication session. Parameter ID PIN 606 is the identity PIN secret 
number, used by financial institution back office and financial account holder during an 
interactive part of an authentication session. Parameter (W/D)#_GEN(ACC#_{XYZ}, 
(W/D)_PIN, ID_PIN, (W/D)$, TX1) 607 is an alphanumeric signature, generated at the 
end of a successful authentication session. (W/D)#_GEN is a function of other 
parameters, listed within the parenthesis above. The only unknown yet parameter is TX1, 
which is a time point at which an authentication session is successfully completed (see 
FIG. 9). Parameter TJNT((W/D)#JjEN(ACC#JXYZ}, (W/D)J>IN, ID_PIN, (W/D)$, 
TX1)) 608 is a time interval, counted from the moment TX1. It specifies an alphanumeric 
signature lifetime for a specific financial transaction -derived internally at financial 
institution the back office server at the end of a successful authentication session. 
Parameter ACC#JXYZ}_TX1 609 is an authentication file name, defined at the end of a 
successful authentication session inside financial institution back office. Parameter 
ACC#__{XYZ} TX2 610 is an authorization file name, defined inside finan cial institution 
back office server at the beginning of a successful entry- data transfer at the beginning of 
an authorization session inside financial institution back office . Parameter BUS# 61 1 is a 
merchant / seller / vendor standard ID number specified by a party at the point of sale 
during an authorization session request. Parameter T- AMOUNT 612 is an exact amount 
of money, required to perform financial transaction -and specified by a party at the point 
of sale (or bya bank teller) during an authorization session request. 

FIG. 7 shows a flow diagram of the EPSL authorization session. It corresponds to 
steps 305 - 306 - 307 in FIG. 3. All together they constitute the authorization session of 
financial transaction. A party at the point of sale can access the financial in s titution back 
office to initiate the authorization session using the same devices / communication lines 
401-405 as financial account holder, when initiating the authentication session (see 
institution FIGS . 4-5) . Though a detailed system and method of performing AAA at 
financial institution b ack office will be described later, certain specific to the 
authorization session features can be described here. 

At decision making stop 701, ACCOUNT NUMBER SEARCH PROGRAM 

module 502 icr n^tW^ "t fmwiil institution b.nck office CPU / dB The back office 
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server utilizes the modules indentified above and additional modules for the authorization 
session, including a TRANSACTION SIGNATURE VERIFICATION PROGRA M 
module 703. a BUSINESS ID VERIFICATION PROGRAM module 705. and an 
ACCOUNT VERIFICATION PROGRAM module 707. 

At decision-making step 704. ACCOUNT NUMBER SEAR CH PROGRAM 
module 502 is activated at the back office server and transitions the authorization session 
to decision-making step 706 } provided the account number is positively verified at the 
financial inotitution back office dB. Otherwise, the authorization session is denied. At 
decision-making step 706, TRANSACTION SIGNATURE VERIFICATION 
PROGRAM module 703 is activated at the financial institution back office CPU and 
transitions the authorization session to decision-making step 708, provided the 
alphanumeric transaction signature is validated at the financial in s titution b ack office dB. 
At decision-making step 708, BUSINESS ID VERIFICATION PROGRAM module 705 
is activated at the financial inotitution back office CPU and transitions an authorization 
session to decision-making step 709, provided a party at the point of sale ID is on a list of 
valid, legal merchants. At decision-making step 709, ACCOUNT VERIFICATION 
PROGRAM module 707 is activated at the financial in s titution b ack office CPU and 
transitions the authorization session to decision-making step 306, provided the predicted 
transaction amount entered by Snaeekt-account holder at the r e spectiv e corresponding 
authentication session is more than or equal to the actual amount? entered by a party at 
the point of sale , while r e questing .duringthe authorization session. At decision-making 
step 306, the financial institution -back office completes authorization and accounting 
sessions' provided the cr e dit / debit EPSL account ea*d-is not on a list of lost, stolen or 
fraudulently used eardsr accounts. This checks again whether there are no suspicious 
issues related to this particular account since the authentication session was completed. 

It can be noted here that a number of program modules 502, 703, 705, 707 and 
307 are incorporated into financial inotitution back office software environment to 
perform an authorization session. As will be seen later, this is part of the automated 
"clocked" AAA sessions, which constitute the system and method implemented at the 
financial inotitution back office to enable financial institution -EPSL technology. 

FIG. 8 shows the EPSL transaction checklist. Pluses mean that a particular 
parameter in a respective row is used during one of AAA sessions, specified at the top of 
the columns. Minuses mean that parameters are not used. 

The columns correspond to the authentication, authorization and accounting sessions. 

FIGS. 9A, 9B and 9C illustrate a synthesis of a timing diagram, a flow chart and 
a functional diagram of the EPSL architecture based on the "clocked" AAA technology. 
One may note that the part, related to the AUTHENTICATION SESSION (a dotted line 
of a non-numbered cell), is already presented in FIGS. 4-5, while the part named the 
AUTHORIZATION SESSION (also a dotted line of a non-numbered cell) is described in 
FIG.7. 

The financial institution back office has GLOBAL CLOCK PROGRAM module 
902. A hardware equivalent is implemented as a silicon digital integrated circuit internal 
clock (with a typical rate approximately within the range (10 - 1,000) MHz). Module 902, 
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which can be fed by similar clock at financial institution back office CPU, synchronizes 
all program modules during AAA sessions. Each financial transaction -beginning from 
the start of the authentication session and up to the end of the authorization and 
accounting sessions is processed depending on their time position, defined by the global 
clock. The global clock synchronizes all program modules. Every program module is 
activated by one of the other program modules once its job is completed. Key 
information elements of financial transactions stored in financial institution b ack office 
dB (for instance, authentication and authorization files) are strictly analyzed and 
differentiated depending on their positions in time, which is a part of a decision making 
process at financial institution back office. The global clock program module -enables 
identification of financial transaction -related timing components and parameters 
identification ^as well as the entire EPSL system of program modules and hardware 
synchronization at financial institution back office. 

A financial An account holder initiates the authentication session with the 

financial institution back office through any of described above devices / communication 
lines by entering a series of numbers (three tiers security protection system described 
above). Once the beginning of a communication session is established, module 
ACCOUNT NUMBER SEARCH PROGRAM 502 is activated, requesting the financial 
account holder to enter a financial institution EPSL an account number. Once the 
financial account holder has entered ACC#_{XYZ} 601, if ACC#_{XYZ} is positively 
verified, module 502 activates module TRANSACTION PIN VERIFICATION 
PROGRAM 503 and stops its own execution. If ACC#_{XYZ} is not verified at the 
financial institution back office dB, the financial transaction -authentication session is 
denied and module 502 stops execution without activating module 503. Decision-making 
routine ACC# 504 is a part of module 502 and makes a decision whether to activate 
module 503 or not, based on ACC#_{XYZ} verification results at financial institution 
back office dB. 

TRANSACTION PIN VERIFICATION PROGRAM module 503, once activated, 
requests the financial account holder to enter a transaction PIN and executes, once the 
W PIN 602 or D_PIN 603 is entered. Decision-making routine T_PIN 506, which is a 
part of module 503, stops module 503 and activates IDENTITY PIN RANDOM 
SUBSET GENERATOR module 505, provided (W/D)J>IN is positively verified at the 
financial institution back office dB. Otherwise, routine T_PIN 506 stops module 505 and 
the financial transaction authentication session is denied. 

Module 505 once activated, generates a request to the financial account holder to 
submit in sequence a certain random combination of digits that constitute a subset of a 
feaneiaI-an_account holder identity PIN secret number ID_PIN 606 and then ex e cute s on 
analyzin ganalyzes a received reply, entered by fi nancial account holder during this 
interactive session (the third tier of financial institution back office security protection). 
Decision-making routine ID_PIN 508, which is a part of module 505, stops module 505 
and activates financial institution back office ACCOUNT CONSISTENCY PROGRAM 
module 507, provided the random subset of digits, entered by financial account holder 
per the request of module 505 is positively validated at financial in s titution b ack office 
dB. Otherwise, routine ID_PIN 508 stops module 505 execution without activating 
module 507 and the fi nancial transaction authentication session is denied. 
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A financial institution back office ACCOUNT CONSISTENCY PROGRAM 
module 507, once activated, requests the fimfieiai-account holder to enter a predicted 
withdraw transaction amount W$ 604 or predicted deposit transaction amount D$ 605 
and executes, once the (W/D)$ is entered. Decision-making routine 509, which is a part 
of module 507, stops module 507 and activates TRANSACTION SIGNATURE 
GENERATOR module 905, provided W$ does not exceed the amount of money 
available on this financial institution EPSL account. Otherwise, routine (W/D)$ 509 
stops module 507 execution without activating module 905 and the financial transaction 
authentication session is denied. 

TRANSACTION SIGNATURE GENERATOR module 905, once activated, 
generates an alphanumeric signature, provided all previous steps 504, 506, 508 and 509 
are successful. Decision-making routine (W/D)#_GEN 511, which is a part of module 
905, stops module 905 and activates module 904, provided the credit / debit financial 
institution EPSL account eafd-is not on a list of lost, stolen or fraudulently used 
eardsr accounts. Concurrently with activating module 904, routine 51 1 sends the 
alphanumeric transaction signature to the financial account holder 510. 

AUTHENTIF IC ATION FILE GENERATOR module 904, once activated, creates 
an electronic record, which contains some or all of the information gathered together 
during the authentication session: ACC#_{XYZ} 601, (W/DLPIN 602 or 603, ID_PIN 
606, (W/D)$ 604 or 605 and (W/D)#_GEN 607. The record is given a file name is 
ACC# {XYZ}_TX1 609, which is a combination of financial institution EPSLt he 
account number and a time mark TX 1 . TX 1 is a time moment, at which file 
ACC# {XYZ}_TX1 907 is generated in financial institution b ack office dB. Practically 
speaking, it is the same time as when the financial account holder obtains his 
alphanumeric signature for a requested financial transaction. The time mark TX1 is 
assigned at the end of the authentication session for the fiftaneial-account holder and 
financial institution back office in this example. The authentication record with the file 
name ACC#JXYZ} TX1 can be created irrespective to which operating system is 
deployed at financial institution back office dB (for instance, UNIX / Solaris or Windows 
NT) Module 904 activates module 901 at the time moment TX1. 

Financial institution backBaek office WATCHDOG PROGRAM module 901, 
starting from the time moment TX1, searches financial institution back office dB after 
each small time interval (which can range for example, from several milliseconds to 
several seconds, depending on actual hardware / software implementation of financial 
institution back office CPU and dB). The search checks whether there is another record 
with the same root name ACC#_{XYZ} and suffix TX2 greater than TX1 (TX2 > TX1). 
Module 901 can work in this mode of operation during time interval T INT 608, which 
starts at TX1 and is set at financial institution theback 0 ff lce t0 a reasonable time to 
perform a predicted financial transaction after the authentication session (for instance, a 
half an hour). Otherwise, it can be chosen by the fewtfteial-account holder during the 
authentication session within certain range (for example, from a quarter of an hour to 
several hours). The record with file name ACC#_{XYZ}_TX2 906, which financial 
institution back office WATCHDOG PROGRAM module 901 is searching for, is created 
during the authorization session, requested by a party at the point of sale from the 
financial institution back office. The authentication session completed at the moment 
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TX1 is followed by the authorization session, which has an intermediate stage of creating 
an authorization record at financial in s titution back office at some later time moment 
TX2 after TX1. The authorization file structure and its role in the "clocked" AAA 
technology will be discussed later along with the authorization session description. 

The financial institution back office WATCHDOG PROGRAM module 901 stops 
searching for an authorization file 906 at the moment TX1 + T INT. Any authorization 
session, initiated by a party at the point of sale after that time will be denied with a 
message that the transaction signature is timed out. The financial account holder will 
need to initiate another authentication session for the same financial transaction -to make 
it happen. Strictly speaking, module 901 will keep searching financial in s titution back 
office dB after the moment TX1 + T INT with gradually increased time interval between 
consecutive search sessions (for instance, double interval for TX1 + TINT < t < TX1 + 
2* T_INT, triple interval for TX1 + 2 * T_INT < t < TX1 + 3 * T_INT, etc.). However, 
its function is changed. When the authorization file is found, module 901 will forbid 
financial transaction -with the error message that financial transaction -is timed out. At 
certain time moment (for instance, TX1 + 10 * T_INT) module 901 completely stops 
searching for the authorization file ACC#_{XYZ}_TX2 906. Any authorization session 
initiated by a party at the point of sale for the same financial transaction -will be simply 

denied from now on. 

The reason module 901 search repetition time interval is getting gradually 
increased after the moment TX1 + T INT is to reduce the load on financial institution 
back office CPU. Limiting the lifetime of transaction signatures and making them 
specific to particular financial transactions -allow eliminating any fraudulent actions 
based on decryption of these signatures. It greatly enhances security in using non-secure 
communication lines and line input / output devices. It is especially important for on line 
financial transaction transactions and makes the EPSL technology a very suitable 
architecture for electronic commerce as well as for off-line financial transactions. 

The financial account holder applies to a party at the point of sale (or a bank 
teller) after obtaining the alphanumeric transaction signature at the end of the 
authentication session. A party at the point of sale (merchant or a bank teller) initiates an 
authorization session with the financial institution b ack office using the same devices / 
communication lines as possible during the authentication session (see financial 
institution GS. 4-5). A party at the point of sale gets from the financial account holder, a 
financial institution EPSL an account number and a financial transaction -alphanumeric 
signature. Then the party at the point of sale adds up a standard business identification 
(merchant) number BUS# 611 and an actual transaction amount of money T- AMOUNT 
612 necessary to perform financial transaction. Those are added to the authorization 
process for accounting processing at financial institution b ack office during the 
accounting session. 

At decision-making step 704, ACCOUNT NUMBER SEARCH PROGRAM 
module 502 is activated, once a party at the point of sale sends the ACC#_{XYZ} 601 
and it is received at financial institution back office. Then module 502 performs two 
steps, provided ACC#_{XYZ} 601 is a legitimate one (positively verified at the financial 
institution back office dB). Module 502 activates AUTHORIZATION FILE 
GENERATOR module 903 at the time moment TX2, which actually symbolizes the 
beginning of the authorization session at financial institution back office. Module 903 



Page 18 of 24 



creates the authorization record with file name ACC#_{XYZ} JTX2 906 in the financial 
institution back office dB, and is kept active during the time when all authorization 
session entry information is passing through steps 706 - 708 - 709 and eventually 
gathered together in the authorization record ACC#_{XYZ}_TX2. In the second step, 
module 502 transitions the authorization session to decision-making step 706, provided 
again the account number 601 is positively verified at financial institution back office dB. 
Otherwise, the authorization session is denied through dedicated device 701 at financial 
institution back office, notifying a party at the point of sale with the error message of 
incorrect financial in s titution EPSL account number. 

WATCH DOG PROGRAM module 901 activated at the moment TX1 keeps 
periodically searching financial in s titution back office dB. It is looking for the 
authorization record, which complements to the authentication record 
ACC#_{XYZ}_TX1 and, once the authorization record ACC#_{XYZ}_TX2 is created, 
module 901 eventually finds it. If the authorization record is created during time interval 
TX1 < t < TX1 + T INT, the authorization session is continuing. Otherwise, it is denied. 
WATCHDOG PROGRAM module 901 right after the authorization file is found and 
positively identified with respect to time it is created, activates TRANSACTION 
SIGNATURE VERIFICATION PROGRAM module 703, ACCOUNTING SESSION 
VERIFICATION PROGRAM module 707 and BUSINESS ID VERIFICATION 
PROGRAM module 705. All these modules start processing information they are looking 
for in the authorization record or keep periodically looking at this record, until the 
expected information appears there after steps 706 - 708 - 709. 

At decision-making step (W/D)# J3EN 706 the financial transaction 
alphanumeric signature is already transferred from a party at the point of sale to the 
financial institution back office and module 703 is activated (if it is not activated yet by 
module 901) and compares alphanumeric signatures in the authentication record and the 
authorization record. In a case they match, module 703 transitions the authorization 
session to decision-making step BUS# 708. Otherwise, the authorization session is denied 
with the error message that the transaction signature is incorrect. 

At decision-making step BUS# 708, a party at the point of sale business ID BUS# 
61 1 is already transferred from a party at the point of sale to the financial institution b ack 
office and BUSINESS ID VERIFICATION PROGRAM module 705 is activated unless 
it was already activated by module 901. Module 705 checks whether a party at the point 
of sale BUS# is on the list of valid, legal merchants and then transitions the authorization 
session to decision-making step T-AM 709. Otherwise, the authorization session is 
denied with the error message that merchant ID is incorrect. 

At decision-making step T-AM 709, a party at th e point of sale specified exact 
transaction amount of money T-AMOUNT 612 transferred from a party at the point of 
sale to financial institution back office, is written to the authorization record 906 and 
ACCOUNTING SESSION VERIFICATION PROGRAM module 707 is activated, 
unless it was already activated by module 901 . Module 707 reads out T-AMOUNT from 
the authorization record 906 and checks whether it is less or equal to the withdraw or 
deposit amount (W/D)$ specified in the authentication record 907. If T-AMOUNT is less 
or equal (=<) (W/D)$ (T-AMOUNT =< (W/D)$), module 707 locks T-AMOUNT at the 
financial account holder financial institution EPSL account to assure the payment to a 
party at the point of sale (after deductions of the transaction fee to the card issuing bank 
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and the discount rate to the acquiring bank or an independent sales organization). This 
completes the accounting session, which is performed next after the authorization 
session. 

If module 502 and 703 positively identifies a financial transaction -after 
comparing authorization record 906 and authentication record 907 at decision-making 
step T-SIGN VERIF 908, the authorization session is transitioned to decision-making 
step 306. Otherwise, the authorization session is denied through dedicated device / 
channel 701 at financial institution back office. 

At decision making step ACC-VERIF 306, the accounting session gets completed 
and the financial transaction -is permitted, provided module 705 and 707 positively 
identified BUS# 61 1 and T-AMOUNT 612 at financial institution the back office dB. 
Otherwise, the financial transaction -is denied. As can be seen, a successful completion of 
the accounting session is an essential part of the entife-authorization process. The 
authorization code is sent to the Saaneial-account holder through ^dedicated device Aoj 
channel 909 from the financial institution back office, provided the accounting session is 
successfully completed and the credit / debit financial institution EPSL account eard-is 
not on a list of lost, stolen or fraudulently used eardsr accounts. This allows checking 
again whntlw there are to insure that no suspicious issues related to this particular 
account have arisen since the authentication session was completed. Authentication and 
authorization records are kept in financial institution back office dB for ongoing 
accounting control until they are archived. 

Several notes about the described above "clocked" AAA technology at financial 
institution back office follow. hnw tn pnrfnrm a techni que for performing 
chargeback using this technology is described. Chargeback is a credit card transaction 
that is billed back to a party at the point of sale, who made the sale. This occurs when 
finoftekl-the account holder disputes a charge on their bill by claiming the product was 
never delivered or fmofteial -because the account holder was dissatisfied with i tthe product 
in some way. If a party at the point of sale and 6ea*i6iakhe_account holder agrees with 
the chargeback and its amount, the financial account holder requests financial institution 
the back office to authenticate a deposit financial transaction -using D_PIN secret number 
during the authentication session (instead of usually used W_PIN for buy / sell 
transactions). Then fiaafteial-the account holder submits to a party at th e point of sale t he 
alphanumeric signature along with the EP-Sir-account number to a party at the point of 
sa le . In other words, chargeback is performed as a regular financial transaction -with the 
only difference that the transaction signature generated at financial institution back office 
is for a deposit tarek^transaction. Then a party at the point of sale requests financial 
institution the back office to authorize this financial transaction -in the same way as a 
withdraw financial transaction-. Once the transaction is authorized at financial institution 
back office, a request to lock the chargeback amount is sent to the acquiring bank or an 
independent sales organization, where this merchant account is residingresides in order to 
guarantee the payment back to ifeafteial-the account holder. EPSfcJhe chargeback 
mechanism n\hvr ^farming thin finnnrinlenables the chargeback transaction -within 
thestandard EPSL architecture (referring back to FIG. 3) without disclosing to a party at 
the point of sale financial account holder private personal information^ 
about the account holder to a party at the point of sale. 
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Th e financial institution back office "clocked" AAA technology is adapted to 
service a party at the point of sale during authorization sessions requested by th e m 
independent of the entry data flow rate for data entry on particular devices and / or 
communication lines. In an extreme case, when a party at the point of sale enters 
ACC#_{XYZ}, (W/D)#J3EN, BUS# and T-AMOUNT manually, modules 703, 705 and 
707 are activated by module 901, once module 502 verifies ACC#_{XYZ} and the 
authorization record ACC#_{XYZ}_TX2 906 is created in the financial institution back 
office dB. This file can be empty for a while, until the following parameters are entered. 
Until then each of the mentioned modules 703, 705 and 707 periodically looks at the 
authorization file, and picks up the parameter of interest as soon as it arrives at financial 
institution back office and is written into the authorization file. Alternatively, in the case 
that a party at the point of sale uses a specialized point-of-sale POS devices, which allow 
for high speed electronic data entry for the listed above parameters, modules 703, 705 
and 707 will find needed parameters in the authorization file ACC#_{XYZ}_TX2 at the 
very first moment they were activated. In this case, modules 703, 705 and 707 could be 
activated by decision-making routines 706, 708 and 709 sooner than by module 901 . That 
depends on specifics of hardware and software implementation of the "clocked" AAA 
technology at financial institution back office. Summarizing, it can be said that financial 
transaction processing time for an authorization session processing time is not limited by 
financial institution back office "clocked" AAA technology, but rather by the entry data 
flow rate at a party at the point of sale locations. 

Authentication sessions in EPSL "clocked" AAA technology are not time limited. 
Also, the authentication sessions include an interactive communicati on session between 
the account holder and the financial institution back office, w hich constitutes the third 
security protection tier.and therefore can-not be replaced by an automated electronic 
interaction between financial account holder devices (for instance, smart cards or mobile 
phones) and financial institution back office. It is because they include an interactive 
communication s e ssions betw e en financial account holders and the financial institution 
ba c k office, whirh ™™-titntr«- th n third r.nr.nrity protection tier.the financial institution 
back office. . This is sort of a trade off in the EPSL technology b etween financial 
institution EPSL technology security protection and inconvenience in using this 
technique. Fortunately, authentication sessions in the EPSL technology are performed 
prior to financial transaction, and the financial account holder can choose a time, when he 
/ she is comfortable to get the transaction signature from financial institution back office. 
The way the financial account holder keeps the transaction signature after the 
authentication session is completed and before it is submitted to a party at the point of 
sale can vary. It can range from just writing it down into a notebook, to storing it 
electronically inside devices like smart cards, digital personal organizers with wireless 
connection capabilities and other electronic devices with read / write memory 
capabilities. 

Smart card technology is an excellent compl e men t tpol to make EPSL technology 
more comfortable for the financial account holder and the third party at the point of sale. 
Smart cards can be used as intermediate information carriers between the financial 
institution back office, which will write financial the transaction- signatures into smart 
cards during authentication sessions, and the financial account holder. Then it-the 
transaction signature can be read out from thesmart cards card at the point of sale 
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locations to speed up the authorization a ossion roquo D ts. sessions, This way there are no 
issues with smart card security protection, since they can not be reused. Even if a smart 
card is lost or stolen before the current financial transaction -signature was deactivated 
during an expected financial transaction at the point of sale location, nobody knows, what 
was the predicted transaction amount (W/D)$ ametart requested and how close thisthe 
transaction signature is to its lifetime end. Moreover, even the fact that the card may still 
carry a signature is not apparent. Therefore, chances are high that even in this case 
fraudulent actions will be unsuccessful. More than that, a smart card may not contain 
financial institution EPSLthe account number-(i^euM For example, the account 
number may be resid ue arried on anJEPSL membership cards). In this case, smart cards 
have absolute security protection against fraudulent actions at any time. 

Mobil phones, network computers or other portable electronic devices having 
information read / write capabilities can be made as convenient as smart cards, 
functioning as intermediate authentication information carriers for one specific financial 
transaction (financial transaction alphanumeric signatures) between financial institution 
back office and a party at the point of sale. 

The last note relates to utilizing fi nancial institution -the EPSL architecture with 
"clocked" AAA technology at ATM stations. A financial An account holder can perform 
an authentication session for a withdraw fiftafteiat-transaction -either before or right 
during operations at ATM stations. In any event, once the authentication session with 
financial institution back office is completed, the financial account holder operates at 
ATM station as at the point of sale location, provided ATM stations hardware and 
software are altered to perform authorization requests in the EPSL architecture. This 
makes money withdraw sessions at ATM stations highly secured and protected against 
information to be looked after, stolen or fraudulently used, while preserving complete 
privacy of personal information. 

Finally, it should be emphasized that the described innovation can be used on-line 
and off-line, and for private and non-private sessions, in all cases for a highly secure 
financial transaction. If a-Snaneialan account holder is not concerned with SmzmeA 
transaction- privacy, the feaReiaTaccount holder name can be placed on the card and 
become one more parameter utilized in the "clocked" AAA technology. Meanwhile use 
of the EPSL financial transaction architecture and the "clocked" AAA technology for 
non^private financial transactions provides improved (essentially, "bullet prove") security 
effbr 0 n-line and off lin" fin™™' tmnnntinn -line transactions. The entire EPSL 
architecture and the "clocked" AAA at financial institution back office for non-private 
financial transactions can be viewed as to fourth security tie r, whereas in J ia case of 
private financial transactions, it is-s*heacts_asa fourth security toyerHmd -tier as well as 
the main embedded privacy layer-as^veHv 

Though the invention has been described in connection with preferred 
embodiments of the system and method for private and secure transactions, it is 
understood that the preferred embodiments have been used for the purpose of illustrating 
the manner in which the invention may be made and used. It should also be understood 
that implementation of other variations and modifications of the invention and its various 
aspects will be apparent to those skilled in the art, and that invention is not limited to 
these preferred embodiments described above. It is therefore contemplated to cover by 
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present invention any and all modifications, variations, or equivalents that fall within 1 
spirit and scope of the basic underlying principles disclosed hereinafter by the claims. 
I claim: 
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